With widespread use of stand-alone microcomputers, the need to interconnect the individual computers and to share information and resources via networks has led to the development by numerous companies of many schemes and devices to make this sharing possible. However, to date, most, if not all, attempts in this area have been met with a fundamental problem. The problem is the requirement for modification of all operating system software packages to run on and accommodate the network system.
A typical microcomputer consists of a keyboard, a processing unit (which will include the central processor unit, memory, and various system control units), a display unit, and a mass storage system. In most cases the mass storage system will be a floppy disk drive system. The storage system usually consists of four parts: the system interface through which the system and the storage system communicate so that the system can send requests for service to the storage system and data can be transferred between the computer and the storage system; the controller (in essence a dedicated microprocessor) which interprets the system requests and executes the required operations to satisfy the requests; the mass storage device interface through which the controller interacts with the physical storage device; and the storage device itself.
In order for the operating software in a microcomputer to use the storage system, there are normally two interfaces--the low level hardware interface and a higher level software interface.
The low level hardware interface refers to the system interface mentioned above as being part of the storage system. Associated with the system interface is the protocol used so that commands and data can be successfully transferred between computer and controller. In most microcomputers the system interface is connected directly to the microcomputer bus, in which case the protocol is the same as is used to access other devices on the bus. However, the storage system may be external to the computer and interfaces to the computer in a different manner. In all cases there must be a well defined physical protocol in order for the computer to communicate with the storage system.
The higher level software interface refers to the way in which software is used to command the storage controller. The actual commands available; the order in which commands can be delivered; when data is to be transferred; and how status information can be examined are examples of the functions of the software interface. Software in the computer usually calls upon established routines ("device drivers") present in the computer (either in ROM or in the operating system) to handle the software interface. However, it is possible for software to perform its own interface if the program designer desires.
As an example, in most floppy disk systems, the hardware interface consists of a floppy disk controller module (FDC). This controller typically consists of a special purpose microprocessor control device. Communication between the FDC and the microcomputer processing unit is accomplished through a well defined protocol. This protocol varies between machines. In most cases the FDC is connected to the data/address/control bus of the microcomputer. Commands are passed to the FDC and data is transferred to and from the FDC using the protocol.
A disk is logically divided into concentric circular tracks, which are further subdivided into units called sectors. All operations performed with the disk are done in terms of these units. Typical operations include; read a sector or track, write a sector or track, and format a track. To perform the operations, the microcomputer processing unit addresses the FDC, passing it a command and any required data. The FDC will then execute the desired command. When finished, the FDC will signal the processor and provide status information, and possibly data if necessary.
Other mass storage systems are similar in concept to the floppy disk drive system.
Other network designers have attempted to replace the software interface in order to install their hardware into the computers. By replacing the existing device drivers with their own, the designers can make the network usable by other software that used the original device drivers. The problem with this method is that future releases of operating systems may include new software that is not compatible with past device drivers, thus requiring that the network designer rewrite the drivers for new releases. This technique of replacing software is called "patching" and has many inherent disadvantages, future incompatibility being just one. The other disadvantage to "patching" the operating system is that some application programs will supply their own device drivers, and therefore will not be able to use the network. Also, the user is dependent on the network supplier to furnish the patches for any operating system the user may desire to install in his system.
Background patent references of general interest are: U.S. Pat. No. 4,399,504 of Ronald L. Obermarck et al issued Aug. 16, 1983; U.S. Pat. No. 4,303,990 of William H. Seipp issued Dec. 1, 1981; U.S. Pat. No. 3,975,712 of Edward C. Hepworth et al issued Aug. 17, 1976; U.S. Pat. No. 4,399,503 of Kenneth R. Hawley issued Aug. 16, 1983; Canadian Pat. No. 1,124,883 of David A. Brereton et al issued June 1, 1982; Canadian Pat. No. 1,145,854 of John Vivian et al issued May 3, 1983; Canadian Pat. No. 1,124,878 of David A. Brereton et al issued June 1, 1982 and Canadian Pat. No. 1,106,073 of Richard A. Lemay et al issued July 28, 1981. Of particular interest is U.S. Pat. No. 4,399,504 of Obermarck et al which teaches a software method and means for sharing of data resources in a local multi-processing multi-programming environment by applications executing on one or more central electronic computer systems.
It is an object of the present invention to provide the capability of resource and information sharing from a network system of a microcomputer system, while at the same time avoiding the problem of the need to modify the software package for the operating system to run on and accommodate the network system. It is a further object of the present invention to provide a network interface for a stand-alone microcomputer which will be invisible to application programs, thereby enabling existing software to be run unchanged on the microcomputer network system. In this way the software base available to the user is not decreased in size as would be the case in adding to the software package to accommodate the network system.
It is a further object of the present invention to replace the storage system hardware of the microcomputer system with different interface hardware which will make the system interface function in the same manner as the original interface. In this way all past, present and future software designed to work with the original storage device will work with the hardware of the present invention.